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INTRODUCTION 


Information  systems  are  now  crucial  to  most  business  functions,  not  only  at  the 
operational  level  but  also  in  helping  managers  to  compete  effectively  and  efficiently 
in  the  market  place.  Consequently,  companies  are  faced  with  the  problem  that 
demand  for  new  computer-based  information  systems  greatly  exceeds  the  systems 
development  capacity  of  their  l/S  department.  This  underlines  the  importance  of  the 
project  selection  procedures  which  should  allocate  scarce  systems  development 
resources  in  a  manner  that  will  provide  the  best  leverage  for  the  company's  objec- 
tives. 

How  do  most  companies  discriminate  between  different  project  requests?  More 
importantly,  does  the  project  approval  process  work  effectively?  The  answer,  accord- 
ing to  the  research  results  discussed  herein,  is  mixed. 

The  current  project  approval  methods  were  developed  alongside  the  evolution  of  tra- 
ditional transaction  processing  systems  and  are  thus  most  appropriate  for  evaluating 
those  specific  system  types.  We  will  argue  that  the  typical  project  evaluation  proc- 
ess is  not  valid  when  it  comes  to  assessing  systems  whose  main  purpose  is  to  sup- 
port managerial  decision-making.  Applying  current  project  approval  methods  to 
management  support  systems  can  eliminate  potentially  valuable  systems,  accept  sys- 
tems of  little  value,  or  worse  ~  prevent  them  from  even  being  proposed. 

Management  support  systems  need  a  separate  evaluation  procedure.  The  type  of  system 
under  consideration  should  be  determined  at  an  early  stage  and  the  evaluation  proc- 
ess suitable  for  that  particular  system  type  should  be  followed.  Use  of  the  appro- 
priate evaluation  process  will  do  much  to  satisfy  current  demand  for  new  systems 
while  an  inappropriate  process  will  be  an  impediment  to  the  successful  evolution  of 
the   l/S  function. 

This  paper  starts  with  a  review  of  current  user  demand  for  systems.  This  will  reveal 
that  although  management  support  systems  are  generally  recognized  as  being  espe- 
cially appropriate  to  managers'  most  important  tasks,  the  number  of  these  systems 
being  developed  does  not  match  their  increased  demand. 

Then  we  focus  on  the  current  project  approval  process.  On  the  basis  of  a  survey 
carried  out  among  user  managers,  the  relative  importance  of  various  criteria  in 
project  proposals  is  discussed.  This  survey  also  enables  us  to  understand  how  man- 
agers judge  the  budget  and  schedule  estimates  presented  in  project  proposals.  Addi- 
tionally, it  shows  managers'  perceptions  of  the  different  factors  regarded  as 
important  in  project  approval  and  of  the  influence  carried  by  various  managers  in  this 
process. 

On  the  basis  of  this  evidence  we  present  a  critique  of  the  current  project  approval 
process.  Transaction  processing  and  managerial  support  systems  are  fundamentally 
different  in  their  justifications.  Incremental  modifications  to  tighten-up  the  current 
process  miss  the  point  altogether.  Our  recommended  dual-track  process  insures 
effective  evaluation  of  all  system  types.  This  new  approach  to  project  approval 
should  also  prove  useful  in  the  evaluation  processes  associated  with  further  devel- 
opments of  computer-based  applications  such  as  CAD/CAM  and  office  automation. 


«  The  authors  would  like  to  express  their  thanks  to  Judith  Quillard  for  her  construc- 
tive comments.  Part  of  the  data  used  in  this  paper  was  presented  by  Hong-Kien  Ong 
in  an  unpublished  MIT  Master's  thesis  supervised  by  Dr.  Robert  M.  Alloway. 
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TRENDS  IN  THE  DEMAND  FOR  NEW  SYSTEMS 


We  will  first  look  at  the  nature  of  the  demand  for  new  computer-based  information 
systems  in  a  number  of  typical  industrial  companies.  The  data  comes  from  an 
extensive  questionnaire,  the  User  Needs  Survey  (UNS),  administered  to  1058  user  and 
l/S  managers  in  nineteen  companies.  A  more  exhaustive  analysis  of  user  needs 
based  on  this  survey  is  presented  in  Alloway  (1,  2,  3  and  4)  but  we  would  like  to 
select  certain  points  to  emphasize  the  project  selection  issues. 

For  the  purpose  of  this  study  systems  were  divided  into  four  types  -  monitor,  excep- 
tion, inquiry  and  analysis.  These  are  defined  in  Figure  1.  The  first  two  types,  moni- 
tor and  exception,  are  often  referred  to  as  transaction  processing  systems  (TPS). 
These  are  often  the  "life-blood"  of  the  company  ~  of  prime  importance  at  the  oper- 
ational level.  Examples  are  accounts  receivable/payable,  inventory,  order  entry  and 
purchasing.  These  systems  capture,  store,  manipulate  and  report  large  volumes  of 
structured  data.  Collectively  they  constituted  eighty  percent  of  all  installed  systems 
in  our  sample. 

Inquiry  and  analysis  systems  are  often  referred  to  as  management  support  systems 
(MSS).  These  are  usually  interactive  systems  whose  purpose  is  to  support  the  effec- 
tiveness and  productivity  of  managers  and  professionals.  Such  systems  need  to  be 
flexible  and  under  the  user's  direct  control,  i.e.,  the  user  determines  the  output  con- 
tents of  an  inquiry  or  the  analytical  sequence  of  analysis  systems.  Another  charac- 
teristic worth  noting  is  their  evolutionary  nature.  Users  request  new  functionality  on 
the  basis  of  their  increased  understanding  of  the  decision  itself  gained,  in-part 
through  the  use  of  the  system.  For  this  reason  it  is  not  always  easy  to  define  the 
scope  of  an  MSS  project  in  the  proposal  stage.  Typical  examples  are  cash  flow 
projections,  dynamic  production  scheduling,  and  sales  forecasting. 

In   the   companies  studied  the   overall    demand   for  new  systems   was   274%  larger  than 

l/S's    capacity    to  supply.      This    level    of    demand    is    unlikely    to    be   met    in   the    near 

future,    either    by  attempts    at    increased    programmer    productivity    or    by    incremental 

increases    to    the  new    systems    development    budget.      This     inability    to    meet    user 

demand    stresses  the    importance   of    determining  which    systems  should   be   developed 

and  therefore  the  importance  of  a  suitable  method  of  assigning  priorities  for  system 
development. 

The  structure  of  demand  by  system  type  offers  further  insights.  Figure  2  shows  that 
only  37%  of  total  demand  can  be  supplied.  However,  looking  at  demand  by  system 
type,  we  see  that  monitor  and  exception  systems  (TPS)  have  a  materially  better  sup- 
ply/demand ratio  than  do  inquiry  and  analysis  systems  (MSS).  Monitor  and  exception 
systems  had  52%  and  47%  of  demand  satisfied  while  inquiry  and  analysis  systems 
had  only  33%  and  19%  respectively.  Considering  the  disproportionately  low  percent- 
age of  demand  for  analysis  systems  being  supplied,  does  this  imply  a  consistent 
bias  against  the  approval  of  these  types  of  projects? 

If  true,  the  seriousness  of  such  a  bias  is  apparent  from  a  look  at  a  measure  of  the 
importance  of  the  different  system  types  to  managers.  Figure  3  shows  how  the  four 
system  types  were  rated  for  being  relevant  and  appropriate  to  managers'  most 
important  tasks.  For  example,  the  144  Analysis  systems  represent  only  10%  of  the 
systems  frequently  used  by  managers,  however,  fully  83%  of  these  systems  are  rele- 
vant and  appropriate  for  those  managers'  most  important  tasks  and  decisions. 
Conversely,  908  monitor  systems  are  frequently  used  by  managers,  whereas,  only 
36%  of  them  are  considered  both  relevant  and  appropriate  to  managers'  most  impor- 
tant tasks.  This  dramatic  contrast,  83%  versus  36%,  has  resulted  in  the  equally 
dramatic  shift   in  user  demand  reflected  in  Figure  4. 
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DEFINITIONS  OF  SYSTEMS  TYPES 


COMPUTER-BASED  INFORMATION  SYSTEMS 

CBIS 


TRANSACTION  PROCESSING 
TPS 


MANAGEMENT  SUPPORT 
MSS 


MONITOR 


EXCEPTION 


INQUIRY 


ANALYSIS 


SHORT  NAME 


DESCRIPTION  OF  I/S  SYSTEMS  TYPES 


MONITOR 


THE  SYSTEM  MONITORS  DAILY  DETAIL  TRANSACTION  ACTIVITY 
PRODUCING  STANDARD  REPORTS  ON  A  FIXED  SCHEDULE  (DAILY, 
WEEKLY,  AND/OR  MONTHLY). 


EXCEPTION 


THE  SYSTEM  PROCESSES  DAILY  DETAIL  TRANSACTION  ACTIVITY 
BUT  PRODUCES  EXCEPTION  REPORTS  WHERE  THE  DEFINITION  OF 
THE  EXCEPTION  CONDITIONS  ARE  FIXED. 


INQUIRY 


THE  SYSTEM  PROVIDES  A  DATABASE  WITH  FLEXIBLE  INQUIRY 
CAPABILITY  ENABLING  MANAGERS  TO  DESIGN  AND  CHANGE  THEIR 
OWN  MONITORING  AND  EXCEPTION  REPORTS. 


ANALYSIS 


THE  SYSTEM  PROVIDES  POWERFUL  DATA  ANALYSIS  CAPABILITIES 
(MODELING,  SIMULATION,  OPTIMIZATION,  OR  STATISTICAL 
ROUTINES)  AND  THE  APPROPRIATE  DATABASE  TO  SUPPORT 
MANAGERIAL  DECISION  MAKING. 


Figure   1.        Definitions  of  Systenns  Types 
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Figure  2.        Systems  Supply  and  Demand  by  Type 
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Figure  3.        Relevant  and  Appropriate  Systems  by  Type 
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Figure  4.        Demand  Growth  Rate  by  Type 


TRENDS   IN  THE  DEMAND  FOR  NEW  SYSTEMS 


To  summarize,  the  level  of  demand  for  new  systems  is  substantially  greater  than  the 
available  systems  development  capacity.  The  demand  mix  by  system  type  has  also 
changed,  with  a  significant  increase  in  the  demand  for  MSS.  Yet,  in  spite  of  this,  a 
dramatically  smaller  percentage  of  MSS  systems  are  being  developed  (19%)  than 
would  be  suggested  by  the  relevance  and  appropriateness  of  MSS  to  users'  most 
important  needs  (83%).i  We  suspect  that  only  a  systematic,  ingrained  bias  against 
MSS  projects  would  have  been  able  to  produce  such  an  anomally  in  modern  business. 


1        (For  an  indepth  discussion  of  user  managers'  systems  needs,  see  Alloway  (2).) 
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PROJECT  INITIATION  WITHIN  THE  PROJECT  LIFE  CYCLE 


The  previous  section  discussed  the  serious  mismatch  between  managerial  needs  and 
available  systems  which  are  both  relevant  and  appropriate.  A  significant  imbalance 
between  supply  and  demand  by  systems  type  is  the  result.  But,  what  is  the  cause? 
We  contend  that  the  project  selection  process  is  biased  against  approving  MSS  pro- 
posals. This  section  discusses  the  steps  in  the  project  initiation  stage  to  determine 
key  managerial  decision  points  which  explain  where  biases  may  affect  the  project 
approval  decision. 

The  complexities  associated  with  systems  development  have  prompted  numerous 
methodologies  and  models  (5,6).  These  conceptualizations  are  the  result  of  questions 
raised  by  first  and  second  generation  systems  projects.  Most  of  this  literature  has 
emphasised  the  design  and  programming  phases  as  these  are  the  most  readily  per- 
ceived areas  of  budget  overruns.  The  postulated  ideal  has  been  a  plan  of  the  phases 
in  a  project's  life,  accurately  predicting  their  duration  and  resource  requirements.  The 
project  initiation  process,  that  is,  the  very  real  and  critical  activities  which  precede 
project  selection  and  funding,  has  been  largely  ignored.  This  is  a  surprisingly 
important  omission  considering  the  financial  implications  of  selecting  the  wrong 
projects,  implemented  but  irrelevant  systems,  and  outright  project  failure.  Even  more 
damaging  are  the  promised  benefits  which  are  not  realized;  the  alternative  investment 
opportunities  which  are  lost;  and  the  misappropriation  of  management  time  and  atten- 
tion. 

Why  has  so  little  emphasis  been  placed  on  the  project  initiation  stage?  Because,  it 
is  generally  assumed  that  the  "right  answer"  is  already  known:  that  project  selection 
should  be  based  solely  on  hard  cost-benefit  analysis.  As  we  shall  see  later,  this 
perception  is  shared  by  a  majority  of  the  respondents  to  the  User  Needs  Survey. 
The  belief  is  that  each  project  can  be  reduced  to  a  calculation  of  discounted  cash 
flows,  return  on  investment,  or  pay-back.  We  will  later  examine  the  validity  of  this 
assumption. 

We  will  use  a  model  of  the  project  life-cycle  defined  in  Alloway  (7).  The  steps 
involved  in  the  initiation  stage  are  summarized  in  Figure  5.  The  process  starts  with 
opportunities  generated  by  changes  within  the  organizational  context  or  in  its  relevant 
external  domain.  Successful  informal  or  formal  search  results  in  a  recognized  felt 
need.  Innovative  insight  combines  a  potentially  feasible  solution  with  a  felt  need  to 
create  an  embryonic  task.  These  tasks  have  to  be  sold  informally  within  the  user 
department  and  to  the  l/S  department  which  will  be  asked  to  participate  in  preparing 
the  proposal.  Only  a  small  proportion  of  the  opportunities  (represented  by  the  wavy 
lines)  ever  become  proposals   involving  computer-tjased   information  systems. 

Proposal  preparation  is  a  small  project  in  its  own  right  requiring  a  certain  amount  of 
resource  allocation.  To  activate  this  process,  task  planning  and  some  ground-work 
needs  to  be  done  by  managers  with  a  vested  interest  in  the  outcome.  Only  if  the 
ideas  behind  the  project  can  be  sold  (without  a  proposal)  will  the  investment  in  pro- 
posal preparation  actually  be  made.  The  proposal  work  thereafter  is  divided  between 
the  l/S  department  which  assesses  the  technical  feasibility  and  estimates  the  devel- 
opment costs,  and  the  user  department  which  estimates  the  benefits.  This 
preliminary  conceptualization  of  the  system,  its  functionality  and  design,  and  the 
cost/benefit  estimates  constitute  the  project  proposal  which  is  evaluated  during 
project  selection.  The  proposal  is  usually  incomplete  and  incorrect;  patched  together 
by  user  and  l/S  managers  with  ambiguous  objectives,  other  full-time  responsibilities, 
and  an  understandable  motivation  to  "cook-the-numbers"  until  the  project  promises 
the    required   financial    return.     The    project    approval    committee,    however,    has   dozens 


PROJECT   INITIATION  WITHIN  THE  PROJECT  LIFE  CYCLE 


I 


V 

V 

CD 

n 

01 

o 

ion  of 
ional 
rs 

u 
> 

Si 

■n  o 

4-* 

y 

a 
« 
o 

«->   3 

rt 

a. 

<B    Z     ° 

11 
CC 

m 

_^ 

•r  a. 

n  -^ 

n)  o 

3 

o 

inclu 
add 
fact 

0(1 

S    0 

■S  a 

O    B 

> 

o. 

0 

0    h 

n  a- 

o  « 
3   tl 

e 

n 

a 

to 

Id 

«  o 

a 

c 
o 

■H 

.— «   "pj 

>~ 

>• 

to  o 

<u 

U 

Id  n) 

C   n 

?r-  >^ 

>,'.s 

u   o 

y  j3  -o 

i.    «  XI 

3    O.  >% 

<d    (V    U 

o   0)  xi 

c 

0          "O 

«    -O     4J 

3  °  2 

>-^   >    (d 

a   t.   3 

O   -H     C 

4)  "^ 

n1 

V    O    -u 

O.   3    0 

U     U 

e 

00  •*-• 

>    4> 

rd  T)    u 

M  u-i    « 

O    00  u 

Id 

-0  <" 

Id 

>   to  •" 

o 

a 

o 

Id  tJ 
a.  c 

ID  i! 
T3    I) 


a 


c 
o 

c    - 
Id 


o 

u  m 

^  <u   p 

Id  4^  41  i" 

g  — >  O  Id 


0)        oC 


3 


o  c 

"-I   o 

5*  ° 

3§ 


E 

0) 

tl 

h 

)4 

>. 

Id 

F 

ID 

3 

U    V 

■^ 

s> 

tl    u 
Id   0 

C 
IV 
T3 

0 
73 

Id 
w 

0)    I. 

01  a 

•22 

.^   a.  a 

•t;  a  u 
■*j  o  .- 


0) 

o  S 
c  c 

O    3 


V  (0 

J3  l< 


O  JS 

O   It 


00  Id 

u  a 
o  o 

4-<     lu 

Id   M 
I)  .^ 


uB 

O    tl 

a  o 

a  a 
3  a 

m   o 


C 

U  ^  -H 

•-<  -^  Id  —  u 

"J    P    o    Id  -H 

■fl    S   C   3  III    a) 

-.    O  o  ^  u    g 

O   o   1)   3  Id    o 

a,  u  .u   u  6   u 


^^ 


o  c 
■M  si 

M    nj 

Id  u  o 
o  a.  o 

Ul  01    u 


H 
U 
< 

O 

o 

(k 

Q 
U 
N 

< 
Pi 
M 
2 
U 
O 


Figure  5.        Project  Initiation  Stage  of  the  Project  Life  Cycle 
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of   projects   to   evaluate  and   compare,   and   its  knowledge  of  each  is  usually  limited  to 
the  contents  of  the  proposal   itself. 
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PROJECT  PROPOSAL  CONTENTS 


The  User  Needs  Survey  asked  managers  about  the  required  contents  of  project  pro- 
posals in  their  companies  —  what  topics  must  be  included.  Managers  rated  15  poten- 
tial topics  on  a  scale  from  desirable  to  required.  These  topics  are  listed  in  Figure  6 
in  descending  sequence  of  their  average  ratings  on  the  seven-point  scale.  The  top 
four  topics  are  definitely  required  in  project  proposals.  The  middle  seven  are  very 
desirable  but  not  always  present.  And,  given  the  realities  of  too  many  issues  and 
too  little  time,  the  bottom  four  are  seldom  actually  included  in  proposals,  although 
they  would  be  desirable. 

There  is  a  strong  pattern  in  the  ratings  of  these  topics  which  favors  "hard  measures" 
over  "soft  issues".  Figure  7  groups  these  topics  into  four  categories  based  on 
"hard"  versus  "soft"  and  technical  versus  economic  considerations.  As  illustrated  in 
the  accompanying  bar  chart,  "hard  measures"  of  economic  issues  dominate  the  cur- 
rent requirements  for  proposal  contents.  "Hard"  technical  topics  follow  closely, 
whereas,  all  "soft"  topics  fall  below  average.  "Soft"  economic  topics  rate  so  low 
as  to  be  practically  excluded  from  the  proposal  preparation  process. 

Thus  the  concensus  is  that  proposals  do  emphasise  "hard"  economic  topics  over 
"soft"  economic  topics.  However,  few  managers  would  argue  that  soft  economic 
benefits  (topic  K)  are  not  important  in  many,  if  not  most,  application  systems. 
Organizational  change  planning  (N)  is  commonly  accepted  as  important  for  successful 
systems  development  and  implementation  (0).  Ignoring  clerical  job  enrichment  (M) 
carries  hidden  costs  in  terms  of  job  turnover,  training,  morale  and  resistance  to 
change  (see  Markus  (8)). 

Why  then  are  such  "soft"  topics  not  required  in  project  proposals?  We  contend  it  is 
simply  because  they  are  difficult  to  quantify.  "Hard"  and  "soft"  are  really  inappro- 
priate terms  ~  it  should  be  "easier"  and  "difficult"  to  quantify.  Note  especially,  that 
the  "hard"  topics  are  more  appropriate  for  evaluating  TPS  and  that  "soft"  economic 
topics  dominate  the  justification  for  MSS.  Nonetheless,  the  majority  of  effort  in 
proposal  preparation  is  spent  in  building  up  arguments  on  seemingly  objective,  quan- 
tifiable criteria,  because  the  proposal  will  appear  more  authoritative  and  defensible 
when  it  is  backed  by  figures  promising  a  good  financial  return. 
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Figure  6.        Proposal  Contents,  Ratings  by  Criteria 
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PROPOSAL  CONTENTS,  RATINGS  BY  CATEGORY 
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/yOlV  HARD  ARE  'HARD'  PROJECT  SELECTION  CRITERIA^ 


Given  the  degree  of  emphasis  unanimously  attached  by  the  companies  to  "hard"  eco- 
nomic criteria  an  investigation  was  made  into  a  suitable  Return  on  Investment  (ROI) 
range  for  project  approval.  The  question  was  put:  "If  you  could  demonstrate  hard 
dollar  cost  savings  for  a  new  information  system,  what  level  of  ROI  would  be  nec- 
essary to  get  easy  approval?"  The  responses,  as  shown  in  the  frequency  bar  chart 
in  Figure  8  reflect  that  there  is  no  strong  concensus.  Although  most  respondents 
favoured  the  20  -  30%  range,  over  35%  of  the  responses  were  above  this  range  and 
15%  of  the  responses  gave  figures  greater  than  50%.  These  figures  are  well  in 
excess  of  the  financial  targets  a  company  would  set  itself  in  its  annual  report  and 
offer  strong  evidence  that  a  subjective  discount  is  applied  to  the  "hard"  economic 
estimates  in  proposals. 

Further  evidence  of  discounting  was  provided  by  a  question  in  the  User  Needs  Survey 
about  estimates  for  budget,  schedule  and  benefits.  Managers  were  asked  what  kind 
of  revisions  they  would  expect  of  project  estimates  at  various  stages  in  its  life. 
The  average  results  are  shown  in  Figure  9. 

The  variation  in  estimated  benefits  was  not  large,  down  10%.  The  revisions  for 
budget  and  schedule,  however,  do  show  that  managers  will  apply  a  significant  dis- 
count to  estimates  put  before  them.  The  proposal  may  'promise'  a  good  ROI  but  the 
typical  manager  will  expect  a  project  budgeted  for  $100,000  to  come  in  at  $158,000 
and  take  over  1.6  times  longer  to  complete  than  scheduled.  Any  ROI  figure  pre- 
sented will  be  reduced  by  these  subjective  discounts  resulting  from  a  manager's 
experience  with  the  development  of  previous  information  systems.  For  example, 
consider  the  simplest  payback  analysis  graphed  in  Figure  8.  For  a  project  originally 
estimated  to  have  a  20  month  payback  the  anticipated  actual  payback  would  be  33 
months,  65%  worse. 

Thus  although  much  emphasis  is  placed  on  quantifiable  "hard"  costs  and  benefits 
there  appears  to  be  little  faith  in  these  estimates.  Thus,  typical  project  selection 
procedures  are  bound  to  favour  those  projects  where  more  credence  can  be  given  to 
the  estimates  ~  those  with  low  complexity  and  uncertainty.  For  example,  it  is  easier 
to  accurately  estimate  small  TPS  than  large  ones.  And,  likewise,  TPS  are  easier  than 
MSS. 
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Figure  8.        Required  Return  on  investment 
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ANTICIPATED  REVISIONS  TO  PROJECT  ESTIMATES 
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calculation  ignores  the  time  value  of  money. 

Figure  9.        Anticipated  Revisions  to  Project  Estimates 
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THE  PROJECT  APPROVAL  PROCESS 


In  most  corporations  the  project  proposal  is  brought  before  the  relevant  approval 
committee  where  its  merits  are  evaluated.  There  are  usually  guidelines  or  policies  to 
help  in  the  decision-making  process  but,  as  in  the  proposal  contents,  different  criteria 
will  carry  different  subjective  weights  for  each  committee  member.  These  will  be 
the  issues  that  will  determine  the  final  decision. 

The  User  Needs  Survey  asked  managers  to  rate  the  relative  importance  of  16  poten- 
tial criteria  for  approving  a  proposed  system.  The  criteria  are  listed  in  Figure  10  in 
sequence  of  their  importance  based  on  average  ratings. 

Figure  10  has  been  partitioned  into  high,  medium,  and  low  priority  criteria.  Given 
that  user  demand  for  new  systems  is  274%  greater  than  the  supply  capacity  of  l/S, 
the  top  five  criteria  no  doubt  determine  which  projects  are  approved.  The  second 
five  criteria  are  used,  if  necessary,  as  tiebreakers  or  as  ammunition  when  one 
department  opposes  a  particular  project.  The  bottom  six  criteria,  practically  speaking, 
are  nice  but   irrelevant. 

There  was  general  agreement  that  top  management  emphasis  played  the  most  signif- 
icant role.  Because  project  approval  is  normally  an  expensive,  risk-bearing,  go/no-go 
decision  one  can  understand  this  deference  given  to  senior  management.  Next  came 
the  urgency  of  the  user's  need,  then  return  on  investment,  followed  by  criteria 
related  to  user  effectiveness  and  efficiency  increases.  Lowest  in  the  list  came 
interest/challenge  to  the  l/S  staff,  disproving  a  long-standing  belief  among  l/S 
department  critics. 

The  importance  of  urgency  is  food  for  thought.  It  suggests  that  l/S  project  approval 
is  unduely  influenced  by  reaction  to  short-term  needs.  Systems  planning,  ranked 
13th,  is  ineffective  in  prioritizing  or  sequencing  the  systems  which  will  be  imple- 
mented for  business  needs.  Both  the  l/S  development  plan  and  l/S  portfolio  balance, 
ranked  15th,  are  at  the  bottom  of  the  list.  Managers  are  either  unaware  of  the 
rationale  behind  such  plans  or  regard  them  as  an  unnecessary  formality.  This  is 
unfortunate  because  a  check  on  portfolio  balance  could  be  one  of  the  factors  that 
would  recognize  the  overall  nature  of  demand  for  different  system  types,  TPS  versus 
MSS.  It  again  indicates  a  bias  of  the  short-term  over  the  longer  term  business  per- 
spective. We  note  that  "soft"  benefits  which  are  closely  associate  with  MSS  are 
again  given  a   low  rating;  ranked    11th. 
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PROJECT  APPROVAL  CRITERIA  RATINGS 
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Figure    10.        Project  Approval  Criteria  Ratings 
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THE  PROJECT  APPROVAL  "COMMITTEE' 


The  Survey  respondents  also  rated  the  actual  influence  of  key  managers  on  project 
approval  decisions.  Figure  11  lists  their  average  influence  in  rank  order.  The  primary 
User  Vice-President  is  the  dominate  influence,  followed  by  the  Vice-President  of  l/S 
and  the  Primary  User  Manager.  The  formal  committees  chartered  to  make  such  deci- 
sions ranked  4th  and  5th.  The  Programming  Manager  and  Secondary  User  Managers 
ranked  so  low  as  to  be  out  of  the  running. 

The  top  ranked  project  approval  criteria  was  top  management  emphasis.  The  reason 
is  now  clearer;  the  Primary  User  Vice-President  has  the  most  influence  on  the  pro- 
posal decision.  Don't,  however,  discount  the  influence  of  the  Vice-President  of  l/S. 
The  primary  user  department  varies  by  application.  For  one  project  the  relevant  V.P. 
is  the  head  of  Finance,  whereas,  for  anotner  it  is  the  head  of  Manufacturing.  The 
V.P.  of   l/S  is  the  second  most   influential   manager  for   all  projects. 

Figure  12  presents  several  alternative  scenarios  whereby  project  approval  decisions 
are  actually  made.  Apparently,  there  is  an  informal  pair-wise  negotiation  between  the 
l/S  and  Primary  User  V.P.'s  on  a  project  specific  basis  (scenario  1).  This  contrasts 
with  the  official  process  whereby  formal  committees  evaluate  by  comparison  pro- 
posals from  many  user  departments  (scenarios  3  and  4). 

The  situation  of  ten  years  ago  may  have  been  reversed.  l/S  acting  unilaterally  can 
no  longer  railroad  projects  over  reluctant  users  (scenario  5).  Today,  Primary  User 
departments  may  well  have  the   influence  to  force  projects  on   l/S  (scenario  2). 

However,  the  Secondary  Users  are  as  ignored  today  as  in  the  past  (scenario  6).  The 
proportion  of  new  systems  impacting  multiple  user  departments  is  increasing  rapidly 
(most  large  TPS,  database  inquiry  applications,  and  common  systems).  Their  only 
hope  is  to  use  the  l/S  Steering  Committee  as  a  vehicle  to  ensure  that  what  is  good 
for  the  Primary  User  is  not  disasterous  for  the  Secondary  Users.  Unfortunately,  the 
l/S  Steering  Committee  (scenario  3)  is  more  of  a  forum  than  a  decision  making  body. 
The  Primary  User  V.P.  has  sufficient  influence  to  remove  proposals  from  evaluation 
by  ROI  comparison,  forcing  the  V.P.  of  l/S  into  pairwise  project  specific  negotiations 
(scenario  1)  which  are  subsequently  blessed  by  the  l/S  Steering  Committee  or  the 
Corporate  Budget  Committee  (scenario  4). 

Realistically,  the  l/S  Steering  Committee  is  both  a  forum  and  a  decision-making  body 
—  both  a  rubber-stamp  surrounded  by  informal,  sub-rosa  decisions  and  a  formal, 
above-board,  evaluative  committee.  It  depends  upon  the  proposed  project,  whether 
the  intended  benefits  of  the  system  are  primarily  cost-displacement  or 
opportunity-fulfillment.  There  is  a  dual  track  for  project  approval  ~  the  mainline  and 
the  override  tracks.  If  the  benefits  are  primarily  cost-displacement,  then  the  proposal 
follows  the  mainline,  being  accepted  or  rejected  in  comparison  with  other  similar 
projects  based  on  ROI.  For  this  mainline  track,  the  l/S  Steering  Committee  operates 
as  a  formal  decision-making  body. 

When  the  benefits  are  primarily  opportunity-fulfillment,  the  project  would  be  rejected 
by  the  mainline  process.  If  the  qualitative  benefits  are  important  enough  to  the  Pri- 
mary User  department,  then  the  mainline  rejection  decision  is  bypassed  and,  thus, 
avoided.  For  this  override  track,  the  l/S  Steering  Committee  operates  as  a  forum  and 
rubber-stamp. 

The  existance  of  this  dual  track  is  the  result  of  practical  managers  trying  to  get  the 
systems  they  need  but  operating  with  inappropriate  policies  and  procedures.  These 
policies   and   procedures   have  simply   failed   to  take  into  account  the  basic  differences 
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SOURCES  OF  INFLUENCE  IN  PROJECT  APPROVAL 
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Figure   11.        Sources  of   Influence  m  Project  Approval 
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ALTERNATIVE  COALITIONS  IN  PROJECT  APPROVAL  INFLUENCE 
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SCENARIO 
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Figure   12.        Alternative  Influence  Coalitions  in  Project  Approval 
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between  cost-displacement  and  opportunity-fulfillment.  Given  that  most  TPS  are  pri- 
marily cost-displacement  and  most  MSS  are  primarily  opportunity  fulfillment,  it 
introduces  a  project  selection  bias  against  MSS. 

Severe  adverse  effects  result  from  this  bias  against  MSS.  MSS  are  forced  to  go 
sub-rosa  and  become  dependent  upon  the  power  of  the  Primary  User  V.P.  for 
approval.  Many  very  valuable  MSS  are  thus  never  approved  and  some  undesirable 
MSS  do  get  approved.  Pair-wise  negotiation  between  the  l/S  and  Primary  User  V.P.'s 
is  not  a  method  which  assures  that  the  most  valuable  MSS  get  approved.  Current 
proposal  preparation  does  not  investigate  opportunity-fulfillment  benefits  thoroughly. 
The  override  approval  process  does  not  compare  the  qualitative  benefits  of  compet- 
ing proposals.  And  the  sub-rosa  override  track  seriously  weakens  the  l/S  Steering 
Committee. 
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A  CRITIQUE  OF  THE  PROJECT  APPROVAL  PROCESS 


On  the  basis  of  the  evidence  we  have  just  presented  from  the  User  Needs  Survey  we 
will  now  step  back  and  take  a  broader  view  of  the  approval  process.  In  particular 
we  will  try  to  relate  certain  aspects  of  project  approval  to  the  characteristics  of 
demand  for  different  system  types. 

The  proposal  is  used  in  project  approval  as  a  framework  and  basis  for  evaluation. 
First,  as  a  minimum  requirement,  l/S  determines  if  the  project  is  technically  feasible. 
If  this  is  not  the  case  the  project  gets  automatically  rejected  because  the  proposal 
never  gets  finished.  Assuming  the  project  is  technically  feasible,  the  discussion  will 
focus  on  the  points  most  strongly  emphasised  in  the  proposal,  i.e.  "hard"  economic 
benefits.  If  the  project  approval  committee  is  persuaded  of  the  validity  of  the  cost 
and  benefit  estimates  put  before  them  the  project  usually  experiences  no  problems  in 
being  accepted.  What  remains  is  to  allocate  the  priority  with  respect  to  other  sys- 
tems in  the  backlog. 

What  if  the  project  is  justified  by  opportunity  fulfillment  rather  than  cost  displace- 
ment and  hence  does  not  fit  within  the  framework  implicit  in  the  typical  approval 
process?  In  this  case  the  proposal  contents  will  be  of  little  use  as  a  basis  for  eval- 
uation as  the  criteria  emphasised  there  will  serve  only  to  reduce  its  chances  of 
acceptance.  If  the  advocates  have  sufficient  faith  in  their  project  the  alternative  is 
to  side-step  the  formal  procedure  and  to  engage  in  informal  persuasion  and  bargain- 
ing with  the  influential  members  of  the  approval  committee  or  coming  to  a  separate 
arrangement  with  the  l/S  department.  This  we  will  call  the  'override'  process,  usually 
the  scenario  is  pair-wise  negotiation  between  l/S  and  Primary  User  vice-presidents. 
Here  much  will  depend  on  the  project  advocate's  ability  to  play  off  the  cost  of  the 
proposed  system  against  its  importance  and  qualitative  or  "soft"  benefits,  not  to 
mention  personal  credits  he  may  have  built  up  with  other  committee  members  or 
members  of  the  l/S  department.  Thus  a  further  factor  will  be  the  political  strength 
of  the  proponent.     This  process   is  shown  in  Figure   13. 

The  'override'  process  presents  a  number  of  problems.  The  political  power  of  an 
advocate  is  not  a  reliable  method  to  ensure  that  scarce  l/S  resources  are  allocated 
to  the  best  systems.  The  trend  in  systems  demand  shows  that  the  selection  of 
Management  Support  Systems  needs  to  be  done  in  a  fair  but  supportive  way. 
Informal  bargaining  and  'power  politics'  mark  a  departure  from  objective 
decision-making.     Qualitative  benefits  do   not  preclude  objective  evaluation. 

Currently,  "hard"  approval  criteria  are  followed  by  a  string  of  subjective  user-justified 
criteria.  The  communication  of  their  validity  depends  on  the  negotiating  ability  of 
the  Primary  User  VP.  The  resources  and  experience  of  the  l/S  department  should  be 
used  to  help  evaluate  the  qualitative  benefits,  to  validate  their  potential  and  identify 
the  problems  and  risks  of  their  realization. 

One  of  the  questions  that  needs  to  be  asked  is  whether  the  proposal  contents  make 
sense  in  the  approval  process?  The  proposal  contents  place  heavy  emphasis  on 
"hard"  economic  criteria  while  the  approval  process  is  most  sensitive  to  top  man- 
agement emphasis,  user  urgency,  and  effectiveness  increase.  The  proposal  is  really 
an  attempt  at  translating  the  validity  of  the  system  into  a  financial  language  that  will 
communicate  to  top  management  and  will  offer  a  means  of  comparison  between  dif- 
ferent systems.  This  translation  is  necessary  because  the  decision-making  process  is 
removed  from  the  ultimate  users. 

If  it  really  was  possible  to  reliably  estimate  costs  and  benefits,  management  would 
establish    a    policy    for    acceptance    and    prioritization.      With    reliable    estimates    and 
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MODEL  OF  CURRENT  PROJECT  APPROVAL  PROCESS 


!    PROPOSAL  ! 


TECHNICALLY  ! 


I NO-- 


->  REJECT 


FEASIBLE  ? 
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HARD 
BENEFITS? 


NO 


yes 


>  NORMAL  ROI 
PROCEDURES 


OVER-RIDE  PROCEDURE 
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C 
O 
S 
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HIGH        LOW 


HIGH    !     ?      !  REJECT  ' 
I ! 

LOW     !  ACCEPT  \  ?      ! 


NOTE;    the  over-ride  procedure  is  based  on  political  power 

and  costs,  not  the  merits  of  the  qualitative  benefits 


Figure   13.        Model  of  Current  Project  Approval  Process 
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explicit  rules  there  would  be  no  need  for  any  committee  process.  But  this  is  far 
from  being  the  case.  A  description  of  a  system  in  purely  financial  terms  tends  to 
ignore  risl<.,  complexity,  uncertainty,  and  fit  with  corporate  strategy.  It  is  presented 
in  a  standardized  language  managers  understand.  But  to  compensate  for  inherent 
inaccuracies  managers  discount  estimates  put  before  them  according  to  rules  of 
thumb  established  from  previous  experience  --  a  65%  decrease  in  payback. 

The  financial  translation  is  unfortunately  very  susceptible  to  loss  of  meaning  and 
manipulation  by  those  who  know  how  the  process  works.  The  process  will  also 
favor  those  systems  that  lend  themselves  best  to  this  translation  into  quantitative 
cost  displacement. 

Now  let  us  consider  how  this  process  will  treat  the  two  system  types  we  discussed 
earlier  -     TPS  and  MSS. 

Traditional  transaction  processing  systems  constitute  the  majority  of  the  systems 
both  installed  and  in  development.  Companies  have  more  experience  and  thus  greater 
faith  in  the  cost/benefit  estimates  involved  in  developing  TPS.  The  homework  done 
in  proposal  preparation  and  the  subsequent  proposal  contents  emphasize  the  "hard" 
economic  and  technical  topics  more  relevant  to  cost-displacement  TPS.  Also  the 
policies  for  proposal  evaluation  have  evolved  in  parallel  with  the  history  of  these 
systems,  being  the  result  of  feedback  from  these  projects.  Thus  the  proposal  evalu- 
ation will  have  a  bias  toward  TPS. 

What  about  MSS?,  It  is  far  more  difficult  to  describe  in  cost-displacement  terms  a 
system  whose  purpose  is  to  help  managers  make  better  decisions.  So  a  proposal 
for  an  MSS,  adhering  to  the  guidelines  for  a  traditional  TPS,  is  bound  to  be  inappro- 
priate if  not  inaccurate.  Most  MSS  which  do  get  approved  will  have  been  pushed 
through  by  the  'override'  process.  The  advocate  will  have  little  "hard"  economic 
information  to  justify  the  system  and  will  be  taking  a  gamble  on  the  situation.  In 
the  event  the  system  is  a  failure  (as  defined  by  its  reputation  within  the  company) 
the  advocate  looses  face  and  future  systems  of  a  similar  type  will  find  approval  that 
much  more  difficult.  This  constitutes  a  negative  feed-back  loop.  The  next  time  such 
a  system  is  suggested  less  effort  will  be  put  into  the  proposal  as  the  staff  will  feel 
less  confident  that  it  will  be  accepted.  Moreover,  the  Primary  User  VP  will  perceive 
more  personal  risk  and  encounter  greater  difficulty  in  "overriding"  the  standard  ROI 
decision  rule. 

A  further  disadvantage  is  that  the  decision  to  go  ahead  with  an  MSS  is  removed 
from  the  eventual  users,  who  at  the  proposal  stage  are  often  still  not  in  a  good 
position  to  evaluate  the  future  benefits  and  requirements  of  such  a  system.  Also  the 
project  acceptance  process  involves  considerable  delays  which  nullifies  one  of  MSS's 
major  potential  benefits  -  its  timeliness  for  helping  the  decision-maker  when  new 
opportunities  or  concerns  arise. 

Surely,  the  objective  should  be  to  find  a  common  measure  for  the  value  of  different 
systems.  The  popularity  of  cost  displacement  is  the  result  of  the  management  con- 
trols instituted  when  the  TPS  of  early  l/S  lost  budgetary  control  (12). 
Cost-displacement  calculations  are  significantly  more  appropriate  for  TPS  than  they 
are  for  MSS.  One  can  no  longer  estimate  man-power  savings  when  the  quality  of 
decisions  is  the  issue.  However,  cost-displacement  is  not  the  only  way  to  assess 
value.     If  we  agree  that  value  is  the  relevant  measure  we  must  ask  ourselves: 

•  who  can  best  establish  the  value  of  an  MSS? 

•  at  what  stage  can  value  be  reasonably  established? 

•  how  is  this  assessment  to  be  performed? 
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The  Decision  Support  Systems  (DSS)  literature  has  investigated  these  issues  in  con- 
siderable depth  for  the  DSS  subset  of  MSS  (9,  10).  At  the  traditional  proposal  stage, 
the  user  manager  knows  only  the  goals  of  the  project,  not  the  functionality  of  the 
application.  The  purpose  of  developing  a  prototype  is  to  learn  —  to  learn  more 
about  the  business  decision  and  how  it  can  be  supported.  It  is  at  this  stage  that  the 
value  of  an  MSS  can  best  be  assessed.  It  is  the  user  manager  who  has  participated 
in  the  rise  of  the  prototype  who  can  best  assess  the  value.  And,  it  is  the  degree  of 
improvement  in  the  business  function,  leveraged  by  the  MSS,  which  is  the  basis  for 
assessing  the  value. 

If  the  end  user  himself  has  little  sense  for  the  potential  value  and  cost  of  an  MSS 
until  he  has  used  a  prototype,  then  a  senior  management  committee  which  has  had 
no  exposure  to  the  particular  application  cannot  effectively  assess  its  value.  The 
value  of  an  MSS  is  best  established  after  users  have  gained  some  experience  with  a 
prototype. 
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SUCGEST/ONS  FOR  AN  IMPROVED  PROJECT  EVALUATION  PROCESS 


The  evidence  and  argunnents  we  have  presented  show  that  the  evaluation  process 
favors  transaction  processing  systems  over  management  support  systems.  In  order 
to  satisfy  the  current  demand  for  both  categories  of  systems  the  biases  at  the 
project  initiation  stage  need  to  be  dealt  with  and,  if  possible,  there  should  be  incen- 
tives to'  generate  those  system  types  that  will  maximize  the  value-added  to  the  com- 
pany. 

One  of  the  first  steps  is  to  realize  the  category  to  which  a  newly  proposed  system 
belongs.  Since  MSS  and  TPS  have  different  characteristics  they  require  proposals 
with  different  contents  and  a  differentiated  project  approval  process  with  appropriate 
criteria  for  their  evaluation.  Users  must  be  convinced  that  they  will  not  be  ignored 
or  penalized  for  proposing  a  MSS,  where  a  rejected  proposal  will  mean  a  waste  of 
the  user  department's  resources  in  its  preparation  and  loss  of  face  and  time  for  the 
proponents.  Awareness  of  the  properties  of  MSS  needs  to  be  promoted,  by  educa- 
tion of  user  and   l/S  personnel  and  by  a  change  in  the  company's  policies. 

So  what  should  be  the  evaluation  process  for  MSS?  We  have  shown  that  the  present 
'define  and  quantify'  approach  is  inappropriate.  A  purely  qualitative  approach  also 
presents  problems,  as  there  will  be  no  real  means  of  comparison  between  projects 
when  the  decision  is  made  by  a  committee  with  no  real  exposure  to  the  proposed 
system  functionality.  The  problems  associated  with  these  different  methods  are 
summarized  in  Figure   14. 

The  proposed  solution  is  to  place  the  decision  at  the  lowest  management  level  pos- 
sible, while  keeping  it  within  constraints  that  will  prevent  a  misuse  of  resources. 
For  TPS  an  allocation  of  resources  can  be  made  on  the  basis  of  competitive 
cost-displacement  project  proposals.  For  MSS  a  better  solution  may  be  to  allocate  a 
portion  of  the  budget  for  MSS  prototypes  to  each  user  department  or  business  unit 
on  an  overhead  basis.  This  overhead  allocation  would  include  manpower  and  com- 
puter-time and  would  allow  the  user  department  to  develop  a  basic  prototype  MSS 
on  an  as-needed  basis.  The  user  department  will  have  to  decide  for  itself  which 
ideas  to  use  its  allocation  on.  This  prototype  system  (called  Version  0  by  Keen  (9)) 
will  be  small,  quick  to  develop  and  cheap,  fulfilling  only  the  basic  functions  required. 
Any  losses  will  thus  be  low,  not  jeopardizing  the  consideration  of  any  future  MSS. 
The  user  himself  will  very  quickly  get  an  idea  of  the  value  of  the  system  and, 
together  with  the  analyst  working  with  him,  he  will  get  an  appreciation  of  the  cost 
and  value-added  of  futher  development.  On  this  basis  a  formal  proposal  can  then  be 
prepared.  A  summary  of  this  new  two-step  procedure  for  project  approval  is  shown 
in  Figure   15. 

The  other  advantage  is  that  the  user  department  will  be  able  to  initiate  MSS  as 
needs  or  opportunities  arise.  They  will  not  have  to  spend  valuable  time  preparing  a 
premature  proposal  when  for  some  cases  the  bare-bones  prototype  will  be  sufficient 
for  their  needs. 

When  the  user  department  feels  the  MSS  is  worth  further  development,  they  can  now 
prepare  a  more  substantive  proposal  for  the  approval  committee.  The  company 
needs  to  clearly  specify  what  it  considers  the  important  and  valuable  benefits  it  will 
use  to  evaluate  MSS  proposals.  On  the  basis  of  these  guidelines  the  approval  com- 
mittee can  then  decide  on  the  allocation  of  resources  for  this  system  as  a  separate 
project  and  on  a  priority  for  its  development  with  respect  to  the  system  backlog.  A 
list  of  benefits  that  can  be  considered  is  given  by  Keen  (9).  Further  development 
would  then  be  outside  the  general  overhead  allocation  for  that  department's  MSS 
development.     This  process  is  shown  in  Figure   16. 
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Figure   14.        Current  Approval  Process 
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PROPOSED  PROJECT  APPROVAL  PROCESS 
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Figure  15.    Proposed  Approval  Process 
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Figure    16.        Recommended  Project  Approval  Process 
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The  process  so  far  suggested  has  been  reactive.  It  is  still  dependent  on  users  taking 
the  initiative  and  developing  prototype  MSS  and  then,  dependent  upon  the  value  of 
Version  0,  submitting  Version  1  proposals.  Given  the  importance  credited  to  MSS  by 
managers  the  process  should  probably  be  more  proactive  at  the  budget  allocation 
stage.  As  was  shown  in  the  trends  section,  the  increased  demand  for  MSS  will 
require  a  greater  budget  allocation  for  this  system  type. 

A  further  refinement  would  recognize  the  type  of  system  that  would  be  of  most  val- 
ue to  a  strategic  business  unit  (SBU)  in  each  stage  of  its  product  development  life 
cycle.  SBU's  at  an  early  stage  are  primarily  concerned  with  entrepenurial  issues  — 
flexibility,  growth,  market  placement,  product  modification,  etc.  MSS  can  be  of  stra- 
tegic importance  at  this  stage  because  of  their  flexibility  and  effectiveness  orien- 
tation. A  more  mature  SBU  would  place  greater  emphasis  on  efficiency  issues  and 
thus  lean  towards  transaction  processing  systems,  in  either  case  a  plan  for  allo- 
cation by  systems  type  will  provide  the  most  valuable  support  for  the  company's 
strategies.  Allocation  would  be  by  the  two  system  categories  -  TPS  and  MSS-  for 
project  development  with  a  supplemental  allocation  for  MSS  prototypes  based  upon 
the  SBU's  or  user  department's  strategy  or  product  life  cycle.  This  is  shown  in  Fig- 
ure  17. 
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RECOMMENDED  I/S  BUDGET  ALLOCATION 


DISTRIBUTION  WITHIN  SB  Us 
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NOTES:    The  total  budget  for  MSS  projects  and  prototypes  should 
equal  the  overall  allocation  for  MSS  --  moving  over  time 
to  match  user  demand  of  5  8%  and  correct  the  sup p I y / demand 
ratios  by  systems  type. 

The  MSS  budget  should  be  split  approximately  1/3  for 
prototypes  and  2/3  for  subsequent  development  of  MSS 

The  total  by  department  should  equal   that  SB  U  's 
strategic  value  to  the  corporation  --  with  the  breakout 
by  systems  type  related  to  its  en t r e p r eneu r i a  1 / ma t u r i t y 
stage  . 


Figure   17.        Recommended  I/S  Budget  Allocation 
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CONCLUSIONS  AND  RECOMMENDATIONS 


This  paper  has  presented  evidence  that  the  current  project  approval  process  does  not 
reflect  the  gieatly  increased  demand  for  systems  designed  to  support  managers.  Fur- 
ther, we  have  suggested  that  a  major  reason  for  this  is  a  bias  in  the  typical  project 
evaluation  methods  being  used;  a  failure  to  distinguish  between  cost-displacement 
and  opportunity-fulfillment.  To  correct  this  situation  we  offer  some  recohimen- 
dations  for  project  approval: 

1.  Objectives  and  supporting  procedures  should  take  into  account  the  fundamen- 
tally different  natures  of  TPS  and  MSS  projects.  This  will  ensure  an  unbi- 
ased selection  of  those  computer-based  information  systems  that  offer  the 
best  contribution  to  the  company's  strategy. 

2.  When  system  requests  are  received  by  l/S  they  should  be  categorized  as 
either  TPS  or  MSS. 

3.  TPS  should  follow  the  current  proposal  and  approval  process. 

4.  For  an  MSS,  a  prototype  should  be  developed  ~  funded  by  the  users'  allo- 
cated MSS  prototype  budget.  (Approximately  1/3  of  the  MSS  budget  should 
be  set  aside  for  MSS  prototypes  and  allocated  to  user  departments.)  Thus 
the  decision  of  which  prototypes  to  develop  would  be  located  closest  to  the 
actual  need  yet  constrained  from  wasting  resources  by  the  limitations  of  the 
user  department's  MSS  prototype  budget  allocation. 

5.  If  the  user  department  decides  the  MSS  prototype  is  worth  further  develop- 
ment a  proposal  should  be  prepared  based  on  the  experience  with  the  proto- 
type. This  would  enable  the  user  department  to  better  assess  the  value  of 
the  system  and  the  l/S  department  to  better  estimate  its  cost  and  required 
functionality. 

6.  Project  approval,  prioritization,  and  resource  allocation  can  now  be  made 
more  objectively  for  both  TPS  and  MSS.  Subsequent  proposals  to  enhance 
MSS  prototypes  can  now  be  based  on  substantive  estimates  of  costs  and 
benefits  and  be  appropriately  evaluated. 

Allocation  of  l/S  resources  should  be  done  by  user  department  and  system  type. 
TPS  and  MSS  are  fundamentally  different  from  each  other  and  should  not  be  pro- 
posed or  evaluated  by  the  same  procedures  or  standards.  Realistically  differentiated 
management  procedures  for  proposal  preparation  and  project  approval  will  increase 
the  relevance,  appropriateness  and  timeliness  of  implemented  systems  by  removing 
the  existing  bias  against  MSS.  Managers  will  thus  feel  more  predisposed  to  request 
those  system  types  that  will  be  of  value  to  their  department  viewed  within  the  con- 
text of  the  company's  overall  plans.  The  l/S  Steering  Committee  will  also  find  its 
task  more  realistic,  its  decisions  based  upon  more  relevant  proposals,  and  its  effec- 
tiveness less  subverted  by  informal  deals. 

As  in  so  many  other  aspects  of  the  l/S  function  we  have  to  remove  ourselves  from 
the  biases  created  by  early  experiences  with  l/S.  Project  evaluation  should  not  be 
thought  of  in  terms  of  cost  displacement  alone  but  each  system  should  be  assessed 
with  respect  to     its  total  contribution  to  business  objectives. 


"We    are    hampered    not    so    much    by    our    ignorance;    rather,    by    the    many    things  we 
know  which  are  not  true",     ~  unknown. 
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